Fix: Distinguish API failures from user cancellations #5896
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Add abortReason field to Task class to track cancellation source - Update abortTask method to accept reason parameter (user vs api_failure) - Fix cancellation reason logic to use abortReason instead of abort flag - Update ClineProvider calls to specify user cancellation reason - Resolves issue where API failures were incorrectly reported as user cancellations Fixes #5895
dosubot
bot
added
size:S
hannesrudolph
added
the
Issue/PR - Triage
Member
|
The issue isn't with distinguishing, is that the error API request cancelled is happening all the time, this PR would be a bandaid fix |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes issue #5895 where provider connection/API failures were incorrectly triggering "API request cancelled" messages instead of proper error handling.
Problem
When API providers like Gemini experience connection issues or become unresponsive, the system incorrectly reports these as user cancellations instead of API failures. This leads to:
Root Cause
The issue was in the cancellation reason detection logic in
Task.ts. The code was using theabortflag to determine if a cancellation was user-initiated, but this flag gets set totruefor both user cancellations AND API failures, making it impossible to distinguish between the two.Solution
abortReasonfield to the Task class to explicitly track the source of cancellation (user|api_failure|null)abortTaskmethod to accept a reason parameter with default value ofuserabortReasoninstead of the ambiguousabortflagabortTask()to specify the correct reason:abortTask(false, "user")abortTask(false, "api_failure")Changes
src/core/task/Task.ts: AddedabortReasonfield and updated cancellation logicsrc/core/webview/ClineProvider.ts: UpdatedabortTask()calls to specify user cancellation reasonTesting
The fix ensures that:
streaming_failedwith proper error messagesuser_cancelledFixes #5895
Important
Fixes issue #5895 by distinguishing API failures from user cancellations using a new
abortReasonfield inTask.ts.abortReasonfield inTaskclass to distinguish between user cancellations and API failures.abortTask()method inTask.tsto accept a reason parameter (userorapi_failure).Task.tsto useabortReasonfor accurate error reporting and handling.Task.ts: AddedabortReasonfield, updatedabortTask()method, and adjusted cancellation logic.ClineProvider.ts: UpdatedabortTask()calls to specifyuseras the cancellation reason.streaming_failedand user cancellations asuser_cancelled.This description was created by
for 020a899. You can customize this summary. It will automatically update as commits are pushed.